\chapter{Conclusion}

In this chapter, we summarize the project, outline our experience with the 3rd party libraries that we have used, and elaborate on future work that can be done on the project.

\section{Summary}

In our software project, we aimed to design and fully implement an intuitive application for interactive colouring and exporting 3D models for 3D printing.
Within this documentation, we described the whole process behind this work together with our results.

We explained the basics of 3D printing and related works in Part I.
In Part II, we continued with a developer documentation describing our architecture and how we decided to implement the software.
Finally, here, in Part III, and especially in Chapters \ref{ch:min-req} and \ref{ch:results}, we prove that we have successfully fulfilled the goals and requirements initially set in our specification.

The whole application has been successfully verified together with our supervisor Oskár Elek and with our consultants Vojtěch Bubník from Prusa Research, Jaroslav Křivánek, and Tobias Rittig.
Possible future work that can be done together with Prusa Research is discussed later in this chapter.

\section{3rd party libraries}

Now we provide a quick summary of our experiences with the 3rd party libraries we decided to use.

\subsection{Cinder}

Cinder \footnote{https://libcinder.org/} is a C++ library which serves as a wrapper around OpenGL. It provides a multi-platform solution to creating an OpenGL window, handling keyboard and mouse input, simplifies the OpenGL buffer handling and much more. It is written with a modern C++11 standard and seemed like a good fit for our project.

Our experiences were mixed. On one hand, the library performed all the tasks we required and allowed us to spend little time worrying about Linux compatibility. On the other hand, the library itself forced a few very non-practical decisions on us, like the already mentioned C macro in the \texttt{main.cpp} file, which we discussed in Section \ref{sec:app}.

We also suspect, that the Cinder library is the main culprit behind our rather long compile times, since the problem existed basically from the beginning of the development, when the project did not include so much code.

\subsection{Dear ImGui}

Dear ImGui \footnote{https://github.com/ocornut/imgui} is a graphical user interface library for C++. We already discussed our reasons for choosing this library in the Section \ref{subsec:imgui}.

Our experience with this library has been very positive, as we have expected. The library is simple to use and simple to pick up. One of our team members was able to quickly start working with the library within a few days, without any prior knowledge. The limitation of this graphical user interface is the limited support for skinning, though this feature is not important at this time. It is difficult to use for an entirely custom user interface though, as some things are not yet exposed in the API, such as more advanced column layouts.

\subsection{CGAL}

The Computational Geometry Algorithms Library (CGAL) \footnote{https://www.cgal.org/} is the main library we chose to solve the geometry computations for this project, since it included several useful features, which we described in more detail in Chapter \ref{chap:geom}.

The team's experience with this library is conflicting. On one hand, the library performed everything we hoped for very well, did not raise many issues and we did not find any bugs, weird or wrong behaviour. On the other hand, the library is so heavily templated, that sometimes it is very hard to navigate. This problem is furthermore highlighted by its documentation, which is lacking in several places (with phrases like \texttt{Advanced feature.} as the only explanation to a public method). Since it looks to be generated from the code, the code does not provide any more information.

The members who have worked with the library were not satisfied with the library mainly for the user-friendliness, however, it is important to state that once you figure out the API and the general ideas behind the library, it performs well.

\subsection{Assimp}

Assimp \footnote{http://www.assimp.org/} is a library that handles importing and exporting of the models. This library holds a unique space in the C++ libraries for geometry loading and saving, because it is basically the only one which supports so many different formats for both importing and exporting. This makes it almost a must-include in a C++ geometry project and we hoped for an easy and fast integration.

In reality, we have had the most issues with Assimp out of all the libraries used. While the documentation is not plainly generated from code and explains a lot of concepts and ideas, it is not complete and the only thing left is reading the internal source code (not just the header files providing the API, the actual implementation as well). This happened several times during our development (while implementing post-processing during the import, while trying to use Assimp's progress reporters). Exporting a custom built scene (that did not get loaded by Assimp earlier), is only explained in the \textit{Issues} tab on Assimp's GitHub page, which also further highlights the lacking documentation.

We also encountered weird behaviour in the post-processing during the import phase -- we set Assimp to completely remove all degenerate triangles (triangles with an area equal to zero), which is described at length in Assimp's documentation. We found out that this pre-process, while configured exactly as the documentation stated, did not, in fact, remove all degenerate triangles, and we had to implement one additional check, after Assimp finishes.

In conclusion, while this library is the best on the market right now, it still has long ways to go, at least in our experience.

\subsection{Cereal}

Cereal \footnote{https://uscilab.github.io/cereal/} is a header-only library for (de)-serialization. The library has a minimalistic API and a solid documentation which explains all the major concepts behind it.

In our experience, it was very easy to pick up and add to our project and worked really well. So far we have not encountered any issues or found any bugs within the library. We have, however, discovered one limitation which the library imposes on the code it is used on. Any object which is to be loaded from serialized data either has to have a default constructor, or be stored by a pointer. If you have an object stored by value and it is not default constructible, the library will not know how to load it.

\subsection{Threadpool}

Threadpool library \footnote{https://github.com/progschj/ThreadPool} is a \emph{very simple} C++ library providing a simple threadpool. We used this library since we required a basic threadpool without too many features or overhead. This free code is simple, easy to check and functional.

\subsection{FreeType, FTGL and Poly2Tri and Font23D}

While doing research for the \textit{Text} tool on how to take a font file and a text string, and transform the bezier curves into triangle meshes, we found the \textbf{Font23D} library/project.

Font23D is a library/project on GitHub \footnote{https://github.com/codetiger/Font23D} without too much activity, but solving exactly the issue we faced as well. It incorporates the \textbf{Freetype}, \textbf{FTGL} and \textbf{Poly2Tri} libraries to solve the issue and we used it parts of this project in our own. You can read the exact development discussion about this library in Section \ref{sec:fonts}.

We made severe improvements and adjustments to the code from the repository, as the code is mainly written in \textbf{C}, instead of C++.

\subsection{Boost}

Last but not least is the Boost library which came as a pre-requisite for Cereal. Since we already had this library in the project, we decided we might as well use it. In the end, we did not use it for any major features but it was still handy to have around.

We will not discuss the quality of the documentation or the performance of this library, since it is a staple in the C++ environment.

\section{Future work}

In this section, we discuss the future work that could be done on this project. We divide the improvements that could be implemented into several categories:

\begin{itemize}
\item Improving existing core features
\item Adding \textit{quality of life} (QoL) changes to the GUI
\item Extending the toolset of the application
\end{itemize}

\subsection{Improving existing core features}

A few of Pepr3D's features and algorithms were developed by the team from scratch, since no solution satisfying our needs existed. These features are mainly the \textbf{Brush tool} and the \textbf{volumetric Export}. 

The brush tool uses computational geometry to subdivide triangles on the fly, which is not an easy task. Further work could be done by optimizing the brush tool to create better subdivisions and increasing the speed of the tool on bigger and more complex models. Our finished product is the best the team was able to come up with but with some more research, the tool can probably be optimized further.

The volumetric export (meaning the export which extrudes the faces inwards) is also a very complicated task, for which we have not found many solutions in any academic research or commercial products. We think that making this feature more robust would greatly improve the Pepr3D user experience.

\subsection{New quality of life features}

Since Pepr3D is a user-targeted application, the range of features the users have come to expect from the GUI of the program is vast. We implemented the basic subset of, what we think, are the most useful and important features -- such as hotkeys, tooltips and clear and simple user interface. However, there are many more features the users might benefit from, for example the radial menu around the mouse cursor, which we already discussed in Section \ref{sec:features}.

Other quality of life feature we got asked about by our colleagues during the development was a \textit{branching Undo \& Redo history}. This means that the command history would not be linear, but the user could go back a few commands from version B to version A, make new changes to version A, which would take him to version C. He could then compare versions B and C, which are both based on A and decide which he likes better.

The export GUI could additionally benefit from a tighter integration with 3D printing slicers. They could show the user in real time how the exported segments will look like layer by layer after being sliced for 3D printing. Our current visualization is not as advanced as we do not have the necessary data and algorithms for actually slicing the objects. This would make exporting the objects faster as users would not need to run another application.

\subsection{Extending the toolset}

When we designed the application's architecture, we put strong emphasis on allowing a potential developer to extend the toolset by adding other tools. We think we achieved this goal very well, because several of the tools require the same Geometry and Command API, which means we could add the tools and extend the functionality without implementing any additional functionality into Geometry or adding new Commands. This is the intended behaviour for the potential future developers.

If the new tool should require extending either the Geometry or Commands API, we strived to make the code educational -- if you need to create another command, you can read through one or two existing commands and then have a good understanding of how you should create your own.